-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(tile-converter): i3s-converter - mitigate "tiles" module dependency #2517
chore(tile-converter): i3s-converter - mitigate "tiles" module dependency #2517
Conversation
belom88
commented
Jun 16, 2023
•
edited
Loading
edited
- removed Tileset3D & Tile3D dependency
- it gives a memory usage improvement (about 10% for Frankfurt dataset)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confused about the goals of this PR and I worry that we may have a misunderstanding.
The goal is not to hide the generic Tile3D from the tile-converter and replace it with a tiles3d specific class. In fact, this approach seems to significantly increase the amount of format specific knowledge that the converter has to deal with, and taking less advantage of the generic tiles
module.
Regardless there some good typing here - I will approve but wish we had discussed more first.
@@ -163,3 +163,16 @@ export type TypedArrayConstructor = | |||
| Uint32ArrayConstructor | |||
| Float32ArrayConstructor | |||
| Float64ArrayConstructor; | |||
|
|||
export type Tiles3DLoadOptions = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these options defined in the tile-converter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the i3s-converter specific options
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've found that we can use Tiles3DLoaderOptions
here. Fixed in #2520
@@ -7,9 +7,10 @@ import convertB3dmToI3sGeometry, { | |||
getPropertyTable | |||
} from '../../../src/i3s-converter/helpers/geometry-converter'; | |||
import {PGMLoader} from '../../../src/pgm-loader'; | |||
import {calculateTransformProps} from '../../../../tiles/src/tileset/helpers/transform-utils'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these importing across module boundaries? Preferably we should use scoped imports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In tests we use other modules internals to make fake data.
We have different classes:
So it is OK that Initially we decided to get rid of |
TODO: add tests and TSDoc comments for new code in another PR |